home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / c_client.arc / text0056.txt < prev    next >
Encoding:
Text File  |  1993-07-31  |  2.6 KB  |  59 lines
  1.  
  2. >       In order to send a MESSAGE attachment, you have to put it
  3. >  on body-contents.text like you would any other type of attachment. 
  4. >  See the routine rfc822_encode_body() in rfc822.c for how this
  5. >  works.
  6.  
  7.     Yes, I was tracing through yesterday, and found the reference in 
  8. rfc822_encode_body(). You might do implementors a small favor by 
  9. changing:
  10.  
  11. /* case MESSAGE:    */    /* here for documentation */
  12.  
  13.     to "TYPEMESSAGE" so it's easier to grep. ;-) 
  14. (Perhaps you've done this already). I might have found it long ago... 
  15.  
  16. >       I will be the first to admit that this is ugly, hideous,
  17. >  and inconsistent and I'll probably be reincarnated as a banana
  18. >  slug for doing it that way, but it was easier to program that
  19. >  way, both in c-client and in the main programs.
  20.  
  21.     I agree it's ugly. 
  22.  
  23.  
  24. >       Probably I'll get reincarnated as a banana slug right
  25. >  next to a hungry garter snake (or a fellow with a salt shaker)
  26. >  for this, but Internal.DOC is way out of date (almost a year
  27. >  old).  I don't think there are very many lies in it and
  28. >  certainly no egregious ones, but it is missing quite a bit
  29. >  that was added or changed in the past year.  The only 100%
  30. >  reliable document right now is the c-client sources, so when
  31. >  in doubt you should refer to them.
  32. >  
  33. >       I'll probably update Internal.DOC sometime after updating
  34. >  the IMAP2 protocol specification, which is a looming Urgent
  35. >  Problem.
  36.  
  37.     I try to use the sources when I can, but not yet knowing them 
  38. intimately, the fact that most function calls are through function pointers (I 
  39. understand and agree with the reasons for doing this), it makes it difficult to
  40. really find out the logic flow without single stepping (no fun). I find that 
  41. the doc is, as you say, almost always correct; but we're left swinging a bit on
  42. actually using the MIME interface. But this isn't a flame. As long as I can 
  43. work through it somehow...
  44.  
  45.     But, I may have uncovered a bug "somewhere" in the client related to 
  46. the rfc822 attachments. I haven't been able to pinpoint it yet. The scenario 
  47. is, I build the body (with rfc822 attachment sitting in contents.text) and pass
  48. it smtp_mail(). When it returns from that function, the msg.env pointer for the
  49. attachment has been altered, i.e. is non-zero, but isn't a valid envelope. This
  50. causes seg faults immediately afterward when mail_free_body() is called to 
  51. de-allocate the entire body structure. I'm punting temporarily; going through 
  52. the partlist and zeroing envelopes for rfc822 attachments before freeing the 
  53. body.  This could cause me to be re-incarnated as a dodo bird, so I could use a
  54. little help.
  55.  
  56. mike
  57.  
  58.  
  59.